Closes #2395.

What users saw

A workflow with add_reaction always failed at that step. The executor posted to /api/messages/{id}/reactions, but Buzz has no such route, so the 404 aborted the run and prevented every later step from running.

Why it happened

send_message already uses the relay's in-process workflow action sink. add_reaction instead used a loopback HTTP request that depended on an endpoint and authentication path that do not exist.

What changes

• Route add_reaction through the same in-process action sink as other workflow side effects.
• Resolve the target message and workflow owner inside the run's server-resolved community.
• Publish a relay-signed NIP-25 kind:7 event with the workflow owner preserved as the effective actor.
• Persist the reaction row and kind:7 event atomically, then use the normal persistent-event fanout and audit path.
• Treat an already-active identical reaction as a successful idempotent result.
• Give a reaction added again after deletion a fresh event ID, including when both actions happen within one Nostr timestamp second.
• Reject missing or cross-community targets, archived or inaccessible channels, malformed owner keys, and reaction content over the existing 64-character limit.
• Keep the workflow running after a successful reaction so later steps execute.

Regression proof

• cargo test -p buzz-workflow — 149 passed.
• cargo test -p buzz-relay --lib workflow_sink — 17 passed, 2 infrastructure tests ignored by default.
• The PostgreSQL-backed sink regression passed. It verifies the stored kind:7 event, relay signature, owner attribution, workflow marker, reaction-row linkage, duplicate handling, deletion, and same-second re-add.
• The signed live-relay regression passed. It publishes a real workflow and trigger, observes the kind:7 reaction over WebSocket, and confirms the following send_message step still runs.
• just test — all eight repository test groups passed.
• just ci — passed Rust formatting and clippy, TypeScript/Biome and Dart analysis, Rust/JavaScript/Flutter test suites, and Desktop/web builds.

The additional affected-package run, cargo test -p buzz-workflow -p buzz-relay -p buzz-test-client --no-fail-fast, passed the workflow and test-client packages and 734 relay tests. The unrelated api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo test returned the same HTTP 504 both on this branch and on a clean checkout of origin/main at acfbb1bb; this change does not touch the mesh path.

Scope

• This does not add a public reaction REST endpoint.
• It does not change Desktop or mobile reaction rendering.
• Manual workflow triggers still cannot use add_reaction because they do not have a triggering message ID.
• It does not add custom-emoji metadata beyond the action's existing reaction-content field.